home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 262 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.8 KB

  1. Path: oxy.rust.net!usenet
  2. From: pgunn@mail.cbf.com (Paul Gunn)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Constructor Exceptions
  5. Date: Wed, 03 Jan 1996 13:28:11 GMT
  6. Organization: Rust Net - High Speed Internet in Detroit  810-642-2276
  7. Message-ID: <4ce0da$513@oxy.rust.net>
  8. References: <4bud9g$pv5@oxy.rust.net> <4cbhcl$kst@dawn.mmm.com>
  9. NNTP-Posting-Host: pgunn.cbf.com
  10. X-Newsreader: Forte Agent .99c/32.126
  11.  
  12.  
  13. >> Is this behavior parculiar to the Microsoft implementation or is it
  14. >> generally the case?
  15. >
  16. >It is not generally the case.  Compilers that adhere to the standard
  17. >will produce code that does not leak memory in this way.
  18.  
  19. Would you happen to know if Borland or any of the other PC compilers
  20. work properly in this area?
  21.  
  22. >> I couldn't find any other reference to this issue in the ARM or other
  23. >> sources. In any event, it makes me very hesitant to throw exceptions
  24. >> from my constructors. 
  25. >
  26. >I understand your hesitance.  Exceptions are, IMHO, the best way to
  27. >report errors from constructors and overloaded operators.  If your
  28. >compiler does not do it right, you may have to report the error in
  29. >some other way (such as an "ok()" function) or rework your constructor
  30. >so that it cannot fail (possibly by deferring some operations).
  31.  
  32. I agree that using exceptions in constructors is the most elegant
  33. solution. Currently, I'm using a two phase initialization procedure
  34. where any questionable operations are performed in an Init() funtion.
  35. It works ok, but it would be nice if those functions could be
  36. performed in the constructor where they belong.
  37.  
  38. I'll try to make a query to Microsoft to see if they plan on fixing
  39. this problem. Do you know of any portions of the draft standard or the
  40. ARM that address this issue? It would be nice if I could point out a
  41. specific breach in compliance.
  42.  
  43. Thanks!
  44. Paul Gunn
  45.  
  46.